Web Service是一个平台独立的,低耦合的,自包含的、基于可编程的web的应用程序,可使用开放的
XML(
标准通用标记语言下的一个子集)标准来描述、发布、发现、协调和配置这些应用程序,用于开发分布式的交互操作的
应用程序。
历史
web广泛用到的技术:
他们的特点是其
开放性,跨平台性,开放性正是Web services的基础。
近几年来,Internet的迅猛发展使其成为全球
信息传递与共享的巨大的
资源库。越来越多的
网络环境下的Web
应用系统被建立起来,利用
HTML、
CGI等Web技术可以轻松地在Internet环境下实现电子商务、
电子政务等多种应用。然而这些应用可能分布在不同的
地理位置,使用不同的
数据组织形式和操作系统平台,加上应用不同所造成的
数据不一致性,使得如何将这些高度分布的
数据集中起来并得以充分利用成为急需解决的问题。
随着
网络技术、网络运行理念的发展,人们提出一种新的利用网络进行
应用集成的解决方案——Web Service。Web Service是一种新的Web应用程序分支,其可以执行从简单的请求到复杂商务处理的任何功能。一旦部署以后,其他Web Service应用程序可以发现并调用它部署的服务。因此,Web Service是构造分布式、模块化应用程序和
面向服务应用集成的最新技术和
发展趋势。
趋势
内容更动态化
趋势
上述的这些趋势意味着,更加智能的处理,操作和汇总内容变得十分重要。让我们看看按照Web services角度所预示的四个趋势:
两种重要技术
要达到这样的目标,Web services要使用两种技术:
其他像
UDDI和
WSDL技术与XML和
SOAP技术紧密结合用于
服务发现。
支持
技术支持
Web Service平台需要一套协议来实现
分布式应用程序的创建。任何平台都有它的
数据表示方法和
类型系统。要实现
互操作性,Web Service平台必须提供一套标准的类型系统,用于沟通不同平台、编程语言和组件模型中的不同类型系统。这些协议有:
XML和XSD
XML是一种用于标记
电子文件使其具有结构性的
标记语言,是Web Service平台中表示数据的基本格式。除了易于建立和易于分析外,XML主要的优点在于它既与
平台无关,又与厂商无关。XML遵循 W3C 规范的语法要求,形式与内容分离,具有良好的自描述性,同时易于扩展,拥有丰富的第三方开发库,非常适合在不同架构的系统之间进行
信息传输使用。随着XML的应用越来越广泛,在众多应用场景下,XML凭借其优点已经成为事实上的
数据交换标准。XML是由
万维网协会(W3C)创建,W3C制定的XML SchemaXSD定义了一套标准的
数据类型,并给出了一种语言来扩展这套
数据类型。
Web Service平台是用XSD来作为
数据类型系统的。当你用某种语言如VB. NET或C# 来构造一个Web Service时,为了符合Web Service标准,所有你使用的
数据类型都必须被转换为XSD类型。如想让它使用在不同平台和不同软件的不同组织间传递,还需要用某种东西将它包装起来。这种东西就是一种协议,如
SOAP。
SOAP
SOAP即
简单对象访问协议(Simple Object Access Protocol),它是用于交换
XML(
标准通用标记语言下的一个子集)
编码信息的轻量级协议,能够在不同信息系统之间交换
结构化数据,是Web Service的一种主流实现形式。它有三个主要方面:XML-envelope为描述
信息内容和如何处理内容定义了框架,将程序对象编码成为XML对象的规则,执行
远程过程调用(RPC)的约定。SOAP可以运行在任何其他
传输协议上。
SOAP基于
HTTP协议定义了一个框架,描述消息中的内容是什么、是谁发送的、谁应当接受并处理它以及如何处理它们。它通过定义SOAP信封(Envelop)实现
数据格式的标准化,将XML
数据封装于信封之中进行
信息交互,使得异构的系统间能够进行互操作。
Web Service 希望实现不同的系统之间能够用“软件-软件对话”的方式相互调用,打破了软件应用、网站和各种设备之间的格格不入的状态,实现“基于Web
无缝集成”的目标。
WSDL
Web Service
描述语言WSDL 就是用机器能阅读的方式提供的一个正式描述文档而基于
XML(
标准通用标记语言下的一个子集)的语言,用于描述Web Service及其函数、参数和
返回值。因为是基于XML的,所以WSDL既是机器可阅读的,又是人可阅读的。
UDDI
UDDI 的目的是为电子商务建立标准;UDDI是一套基于Web的、分布式的、为Web Service提供的、信息注册中心的实现标准规范,同时也包含一组使企业能将自身提供的Web Service注册,以使别的企业能够发现的
访问协议的实现标准。
Web Service本身其实是在实现
应用程序间的通信。我们有两种应用程序通信的方法:RPC
远程过程调用 和消息传递。使用RPC的时候,客户端的概念是调用服务器上的远程过程,通常方式为实例化一个远程对象并调用其方法和属性。RPC系统试图达到一种位置上的透明性:服务器暴露出远程对象的接口,而客户端就好像在本地使用的这些对象的接口一样,这样就隐藏了底层的信息,客户端也就根本不需要知道对象是在哪台机器上。
软件支持
操作系统离不开丰富的应用软件的支持。同样,Web Service这项技术只有通过日益广泛的应用才能体现出其价值,比较流行的实现方法是使用
.NET 和
Java两种技术,并且两种实现方法可以互相操作;如今我们已经可以看到使用
微软、
Oracle、
SUN、
Borland等不同厂商的Web Service构建工具建立的Web Service应用。
微软.NET
微软的.NET技术应该算是时下最为流行的Web Service 开发技术。首先因为其公司在以前相应的产品就占有相当大的
市场份额,以至使新推出的.NET得以有比较稳定的
用户群;其次也是更重要的是 .NET平台不仅延续了
微软一贯的编程风格,而且还增加了许多支持Web 服务的关键性技术,使得.NET在操作的简单性和执行的稳定性,高效性上达到了一个非常好的结合。
微软的
Visual Studio. NET便是一个便于 Web 服务的
开发工具。
微软的目标是,将其新
编程语言——C#作为Web Service的首选语言。虽然C#看起来与Java类似,但是还有一些Java中没有的独特的功能。.NET技术中用于Web Service 开发的主要工具是ASP. NET。从技术上说,ASP. net 提供了一些超出ASP以前版本的优点(例如:代码和
HTML(
标准通用标记语言下的一个应用)的分离,与
脚本语言相比较,对“真正”的
编程语言如 C# 的支持)。
IBM公司是业界第一家能够提供全面支持Web服务的电子商务基础设施
中间件的公司。通过多年来与W3C(The World Wide Web Consortium)的共同努力,包括
DB2、Lotus、
Tivoli 和WebSphere在内的所有IBM软件都实现了对SOAP、WSDL、UDDI、
Linux、
XML(
标准通用标记语言下的一个子集)、J2EE等开放技术和标准的全面支持。
IBM公司的WebSphere也是比较好的基础架构
软件开发平台。WebSphere软件平台及开发工具包括WebSphere Studio Application DeveloperWSAD 基于J2EE、XML 和Web服务等开放标准,并具备 IBM 在可靠性、扩展性和安全性上的主要优势。WebSphere 是 IBM 在 Web Services策略中的核心平台,它支持所有开发、发布、部署 Web Services应用所必需的开放标准和技术,包括 UDDI,SOAP,J2EE,WSDL,和对 XML 技术集成的增强,这使得它在全球有很多用户。
Borland公司在 JBuilder7中,用户可以用其Borland Web Services Kit for Java和Borland JBuilder MobileSet 3进行更快捷地开发Web Service和
无线应用。这样将使开发者能够在同一个
开发环境中轻松地创建和集成Web Service。新推出的JBuidler8更是针对Web Service开发更提供了方便和高效的方法。
总之,在Web Service开发上,.NET 和Java都是很好的选择,尽管两者都有一些需要完善的地方,但是它们还是最好的开发手段和技术。具体选择哪种开发工具,也是仁者见仁,智者见智的问题。从根本上说,这两种方法没有孰优孰劣的问题,只是根据使用者对这两种方法的掌握程度和对具体语言的偏爱程度来决定。
应用
Web service到底是什么;在什么情况下你应该使用Web service。
研究一下当前的
应用程序开发,你会发现一个绝对的倾向:人们开始偏爱基于浏览器的客户端应用程序。这当然不是因为客户端能够提供更好的
用户界面,而是因为它能够避免花在
桌面应用程序发布上的高成本。发布
桌面应用程序成本很高,一半是因为应用程序安装和配置的问题,另一半是因为客户端和服务器之间通信的问题。
传统的Windows
客户应用程序使用
DCOM来与服务器进行通信和调用远程对象。配置好DCOM使其在一个大型的网络中正常工作将是一个极富挑战性的工作,同时也是许多IT工程师的噩梦。事实上,许多IT工程师宁愿忍受浏览器所带来的功能限制,也不愿在局域网上去运行一个DCOM。在我看来,结果就是一个发布容易,但开发难度大而且用户界面极其受限的应用程序。极端的说,就是你花了更多的资金和时间,却开发出从用户看来功能更弱的应用程序。不信?问问你的会计师对新的基于浏览器的
会计软件有什么想法:绝大多数商用程序用户希望使用更加友好的Windows用户界面。
关于客户端与服务器的通信问题,一个完美的
解决方法是使用
HTTP协议来通信。这是因为任何运行
Web浏览器的机器都在使用HTTP协议。同时,当前许多防火墙也配置为只允许HTTP连接。
许多商用程序还面临另一个问题,那就是与其他程序的
互操作性。如果所有的应用程序都是使用COM或
.NET语言写的,并且都运行在Windows平台上,那就天下太平了。然而,事实上大多数
商业数据仍然在大型主机上以非关系文件(
VSAM)的形式存放,并由
COBOL语言编写的
大型机程序访问。而且,还有很多商用程序继续在使用C++、
Java、
Visual Basic和其他各种各样的语言编写。除了最简单的程序之外,所有的应用程序都需要与运行在其他异构平台上的应用程序集成并进行
数据交换。这样的任务通常都是由特殊的方法,如文件传输和分析,
消息队列,还有仅适用于某些情况的的
API,如
IBMAPPC编程语言的。只有通过Web Service,客户端和服务器才能够自由的用HTTP进行通信,不论两个程序的平台和
编程语言是什么。
什么是Web Service
对这个问题,我们至少有两种答案。从表面上看,Web service 就是一个应用程序,它向外界暴露出一个能够通过Web进行调用的API。这就是说,你能够用编程的方法通过Web来调用这个应用程序。我们把调用这个Web service 的应用程序叫做客户。例如,你想创建一个Web service ,它的作用是返回当前的天气情况。那么你可以建立一个ASP页面,它接受
邮政编码作为查询
字符串,然后返回一个由逗号隔开的字符串,包含了当前的气温和天气。要调用这个ASP页面,客户端需要发送下面的这个HTTP GET
返回的数据就应该是这样:
这个ASP页面就应该可以算作是Web service 了。因为它基于HTTP GET请求,暴露出了一个可以通过Web调用的API。当然,Web service 还有更多的东西。
下面是对Web service 更精确的解释: Web services是建立可
互操作的
分布式应用程序的新平台。作为一个Windows
程序员,你可能已经用COM或DCOM建立过基于组件的
分布式应用程序。COM是一个非常好的
组件技术,但是我们也很容易举出COM并不能满足要求的情况。
Web service平台是一套标准,它定义了应用程序如何在Web上实现
互操作性。你可以用任何你喜欢的语言,在任何你喜欢的平台上写Web service ,只要我们可以通过Web service标准对这些服务进行查询和访问。
新平台
Web service平台需要一套协议来实现
分布式应用程序的创建。Web service平台必须提供一套标准的
类型系统,用于沟通不同平台、
编程语言和
组件模型中的不同类型系统。在传统的
分布式系统中,基于界面(
interface)的平台提供了一些方法来描述界面、方法和参数(
译注:如COM和COBAR中的
IDL语言)。同样的,Web service平台也必须提供一种标准来描述Web service,让客户可以得到足够的信息来调用这个Web service。最后,我们还必须有一种方法来对这个Web service进行远程调用。这种方法实际是一种
远程过程调用协议(RPC)。为了达到
互操作性,这种
RPC协议还必须与平台和编程语言无关。下面几个小节就简要介绍了组成Web service平台的这三个技术。
XML和XSD
可扩展的
标记语言(
标准通用标记语言下的一个子集)是Web service平台中表示数据的基本格式。除了易于建立和易于分析外,XML主要的优点在于它既是
平台无关的,又是厂商无关的。无关性是比技术优越性更重要的:软件厂商是不会选择一个由
竞争对手所发明的技术的。
XML解决了
数据表示的问题,但它没有定义一套标准的
数据类型,更没有说怎么去扩展这套数据类型。例如,整形数到底代表什么?16位,32位,还是64位?这些细节对实现
互操作性都是很重要的。W3C制定的XML Schema(XSD)就是专门解决这个问题的一套标准。它定义了一套标准的数据类型,并给出了一种语言来扩展这套数据类型。Web service平台就是用XSD来作为其
数据类型系统的。当你用某种语言(如VB. NET或C#)来构造一个Web service时,为了符合Web service标准,所有你使用的数据类型都必须被转换为XSD类型。你用的工具可能已经自动帮你完成了这个转换,但你很可能会根据你的需要修改一下
转换过程。
SOAP
Web service建好以后,你或者其他人就会去调用它。
简单对象访问协议(SOAP)提供了标准的RPC方法来调用Web service。实际上,SOAP在这里有点用词不当:它意味着下面的Web service是以对象的方式表示的,但事实并不一定如此:你完全可以把你的Web service写成一系列的C函数,并仍然使用SOAP进行调用。SOAP规范定义了SOAP消息的格式,以及怎样通过HTTP协议来使用SOAP。SOAP也是基于
XML(
标准通用标记语言下的一个子集)和XSD的,XML是SOAP的数据
编码方式。
你会怎样向别人介绍你的Web service有什么功能,以及每个
函数调用时的参数呢?你可能会自己写一套文档,你甚至可能会口头上告诉需要使用你的Web service的人。这些非正式的方法至少都有一个严重的问题:当程序员坐到电脑前,想要使用你的Web service的时候,他们的工具(如
Visual Studio)无法给他们提供任何帮助,因为这些工具根本就不了解你的Web service。
解决方法是:用机器能阅读的方式提供一个正式的描述文档。Web service
描述语言(
WSDL)就是这样一个基于
XML(
标准通用标记语言下的一个子集)的语言,用于描述Web service及其函数、参数和
返回值。
WSDL既是机器可阅读的,又是人可阅读的,这将是一个很大的好处。一些最新的
开发工具既能根据你的Web service生成WSDL文档,又能导入WSDL文档,生成调用相应Web service的代码。
UDDI
Universal Description, Discovery and Integration
为加速Web Service的推广、加强Web Service的互操作能力而推出的一个计划,基于标准的服务描述和发现的规范(
specification)。
以
资源共享的方式由多个运作者一起以Web Service的形式运作UDDI商业注册中心。
UDDI计划的核心组件是UDDI商业注册,它使用XML文档来描述企业及其提供的Web Service。
UDDI商业注册提供三种信息:
White Page包含地址、联系方法、已知的
企业标识。
Yellow Page包含基于标准分类法的行业类别。
Green Page包含关于该企业所提供的Web Service的
技术信息,其形式可能是指向文件或URL的指针,而这些文件或URL是为
服务发现机制服务的。
Web Service开发实例
适合使用Web Service的情况
不适合使用Web服务的情况